The Binder

The role of the binder is twofold:

The binder makes use of the information created when each unit is compiled. This information includes the semantic dependencies of each unit, the date of latest modification of their sources, the presence of various elaboration pragmas, and whether a given unit may be a main program.

The binder has been designed with flexibility in mind. In one mode, it can verify that all objects depend on a consistent set of sources. Given that time stamps of the sources used for a compilation are kept in the object files, this check does not require that sources themselves be present, which is an advantage in commercial settings for software distribution.

Another mode of operation is to verify that the system is up-to-date, that is to say that no source was modified after compilation. In all cases, possible inconsistencies are diagnosed and treated as fatal errors. There are however cases in which this is undesirable. For example, it is irritating to be forced to recompile a large system only because comments were added to a low-level package on which many units depend. An additional option instructs the binder to ignore time stamps and create an elaboration procedure unconditionally. Such an option requires precise understanding on the part of the user, and is certainly not safe, but it may be indispensable in certain circumstances, and will be welcome by experienced programmers.

Finally, the binder is intended to work with other GCC languages, and can produce different output programs. By default, the object file given as input is taken to be the main program. In this case, the binder builds a C file containing the function <#839#>main<#839#>, which is the mandatory main program for a C compilation. This function consists of a series of calls to elaboration procedures, followed by a call to the main Ada program. The intended main program may not even be in Ada, in which case the binder output consists solely of the elaboration calls.